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C-O Diagrams have been introduced as a means to have a visual representation of normative texts and 
electronic contracts, where it is possible to represent the obligations, permissions and prohibitions of 
the different signatories, as well as what are the penalties in case of not fulfillment of their obliga- 
tions and prohibitions. In such diagrams we are also able to represent absolute and relative timing 
constrains. In this paper we consider a formal semantics for C-O Diagrams based on a network of 
timed automata and we present several relations to check the consistency of a contract in terms of 
realizability, to analyze whether an implementation satisfies the requirements defined on its contract, 
and to compare several implementations using the executed permissions as criteria. 

1 Introduction 

In the software context, the term contract has traditionally been used as a metaphor to represent limited 
kinds of "agreements" between software elements at different levels of abstraction. The first use of the 
term in connection with software programming and design was done by Meyer in the context of the 
language Eiffel (programming-by-contracts, or design-by-contract). This notion of contracts basically 
relies on the Hoare notion of pre and post-conditions and invariants. Though this paradigm has proved to 
be useful for developing object oriented systems, it seems to have shortcomings for novel development 
paradigms such as service-oriented computing and component-based development. These new applica- 
tions have a more involved interaction and therefore require a more sophisticated notion of contracts. As 
a response, behavioural interfaces have been proposed to capture richer properties than simple pre and 
post-conditions Q. Here it is possible to express contracts on the history of events, including causal- 
ity properties. In the context of SOA, there are different service contract specification languages, like 
ebXML, WSLA, and WS-Agreement. These standards and specification languages suffer from one or 
more of the following problems: They are restricted to bilateral contracts, lack of formal semantics (so 
it is difficult to reason about them), their treatment of functional behaviour is rather limited and the 
sub-languages used to specify, for instance, security constraints are usually limited to small application- 
specific domains. The lack of suitable languages for contracts in the context of SOA is a clear conclusion 
of the survey [13] where a taxonomy is presented. 

In iflOl C-O Diagrams were introduced, a graphical representation not only for electronic contracts 
but also for the specification of any kind of normative text (Web service composition behaviour, software 
product lines engineering, requirements engineering, . . . ). C-O Diagrams allow the representation of 
complex clauses describing the obligations, permissions, and prohibitions of different signatories (as de- 
fined in deontic logic H3), as well as reparations describing contractual clauses in case of not fulfillment 
of obligations and prohibitions. Besides, C-O Diagrams permit to define real-time constraints. In O 
some of the satisfaction rules needed to check if a timed automaton satisfies a C-O Diagram specification 
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were defined. In ifTTl . C-0 Diagrams are equipped with a formal semantics based on a transformation 
of these diagrams into a network of timed automata (NTA). The contribution of this work pursues the 
further development of our previous work. This time we will focus on the development of different rela- 
tions to check the consistency of contracts, to seek whether an implementation conforms a given contract 
and to compare several implementations. To achieve this goal, we consider a semantics in terms of NTAs 
and we establish relations with the implementations also written in terms of NTAs. 

2 Related Work 

The use of deontic logic for reasoning about contracts is widely spread in the literature since it was 
proposed in Q for modelling communication processes. In (H Marjanovic and Milosevic present their 
initial ideas for formal modelling of e-contracts based on deontic constraints and verification of deon- 
tic consistency, including temporal constraints. In J4[ Governatori et al. go a step further providing 
a mechanism to check whether business processes are compliant with business contracts. They intro- 
duce the logic FCL to reason about the contracts, based again on deontic logic. In Q Lomuscio et al. 
provides another methodology to check whether service compositions are compliant with e-contracts, 
using WS-BPEL to specify both, all the possible behaviours of each service and the contractually correct 
behaviours, translating these specifications into automata supported by the MCMAS model checker to 
verify the behaviours automatically. 

None of the previous works provides a visual model for the definition of contracts. However, there 
are several works that define a meta-model for the specification of e-contracts which purpose is their 
enactment or enforcement. In [2] Chiu et al. present a meta-model for e-contract templates written 
in UML, where a template consists of a set of contract clauses of three different types: obligations, 
permissions and prohibitions. These clauses are later mapped into ECA rules for contract enforcement 
purposes, but the templates do not include any kind of reparation or recovery associated to the clauses. 
In O Krishna et al. another meta-model based on entity-relationship diagrams is proposed to generate 
workflows supporting e-contract enactment. This meta-model includes clauses, activities, parties and the 
possibility of specifying exceptional behaviour, but this approach is not based on deontic logic and says 
nothing about including real-time aspects natively. 

3 C-O Diagrams Syntax and Semantics 

We first introduce a motivation example to understand the diagrams in an easy way. Figure Q] consists of 
three sub-figures, a) depicting a basic structure of a clause, and, b) and c) depicting our running example. 
This example consists in the payment and shipment of an item previously sold during an online auction. 
Thus the action starts after the auction has finished, that is, if the bid placed by the buyer is the highest 
one, then the activities concerning the payment and the shipment of the item start. First, the buyer has 
three days to perform the payment, which can be done by means of credit card or PayPal. After the 
payment has been performed, the seller has fourteen days to send the item to the buyer. If the item is 
not received within this period of time, the auction service has seven days to refund the payment to the 
buyer and can penalize the seller in some way. 

At first sight, the figures are top down hierarchical structures with several boxes and branches. In 
Figure [H we can observe several examples. At the top-left hand side of this figure, Figure [T]-a, we can 
observe the basic construction element called box, also referred as proposition or clause. It is divided 
into four fields. The guard g specifies the conditions under which the contract clause must be taken into 
account (boolean expression). The time restriction tr specifies the time frame during which the contract 
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Figure 1: C-0 Diagrams examples 
clause must be satisfied (deadlines, timeouts, etc.). The propositional content P, on the centre, is the 
main field of the box, and it is used to specify normative aspects such as obligations (O), permissions 
(P) and prohibitions (F), that are applied over actions, and/or the specification of the actions themselves. 
The last field of these boxes, on the right-hand side, is the reparation R. This reparation, if specified by 
the contract clause, is a reference to another contract that must be satisfied in case the main norm is not 
satisfied (a prohibition is violated or an obligation is not fulfilled, there is no reparation for permission), 
considering the clause eventually satisfied if this reparation is satisfied. Each box has also a name at the 
bottom part and an agent at the top part. 

These are the basic boxes, which can be composed by using some refinements. Refinements are 
classified into three types: joining AND -refinements, disjunctive OR-refinements and sequential SEQ- 
refinement. Joining refinements require that all the hanging propositions should be accomplished to 
declare the upper proposition accomplished; on the contrary, disjunctive propositions only require one to 
be accomplished; whereas, sequential propositions require a left-to-right ordered sequential satisfaction 
of every proposition to obtain the same result. In Figure [Be, the root box, which only shows the name 
and guard gi (this guard checks if the buyer is the auction winner) is decomposed into two sub-clauses 
via sequential composition, that is, first the one on the left hand side, Paymentjtem and, afterwards, 
the one on the right hand side, SendJtem. The first one is the obligation (O) of payment with the 
temporal restriction t\, three days in this case, then this obligation is decomposed via an OR-refinement 
into Clause 3 and Clause 4 composing the actions of paying by credit card or PayPal by means of an 
OR-refinement. On the right-hand side we have the obligation (O) specified in Clause 5, which has been 
called SendJtem, including the real-time constraint t% 14 days and a reference to reparation R\. 

Since reparations are references to new contracts, in Figure [TJ-b we can see the diagram correspond- 
ing to reparation R\. It has been called Refund J'enalty, including the real-time constraint ?3, and it is 
decomposed into two subclauses by means of an AND -refinement. The subclause on the left corresponds 
to the obligation (O) specified in Clause 7, which has been called Refund Jiuyer, and the subclause on 
the right corresponds to the permission (P) specified in Clause 8, which has been called Penalty Seller 
regarding the possibility of performing some kind of penalization over the seller by the Auction Service. 

The syntax of C-0 Diagrams was first presented in ifTOl . Next, we just present a brief description of 
the EBNF grammar followed in the diagrams: 



C :— (agent, name, g,tr,0(Cj),R)\ 
(agent , name ,g,tr,P(C2) ,E) \ 
(agent , name , g,tr,F (C2) ,R) \ 
(e,name,g,tr,C\ , e) 



R 



C (And C)+\C(Or C)+\C (Seq C)+ 

a I C 3 (And C 3 )+ | C 3 (Or C 3 )+ | C 3 (Seq C 3 )+ 
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The C-0 diagram semantics is defined by using NTAs (Network of Timed Automata) (T) as semantic 
objects. Here we omit this formal translation and the technical definitions can be found in [1 1]. Instead, 
we present an informal interpretation of the NTA behaviors. When transforming a C-0 diagram into a 
network of timed automata, the nodes of the generated automata are decorated with the set of contractual 
obligations, prohibitions and permissions that are either violated or satisfied. 

Definition 1 (Violation, Satisfaction and Permissions Sets) Let us consider the set of contractual obliga- 
tions and prohibitions CN ranged over cn, cn',. . . standing for identifiers of obligations and prohibitions 
and the set of contractual permissions CP ranged over cp, cp', 

Definition 2 (Decorated timed automaton) 

A decorated timed automaton is a timed automaton (N,no,E,I) (see [T]) where for each n £N we have 
defined the following sets V(n) C CN (the set of the obligations violated in n), S(n) C CN (the set of the 
obligations satisfied in n), and P(n) C CP (the set of permissions granted in n). 

Graphically, when we draw a timed automaton extended with these three sets, we write under each 
node n (between braces) its violation set V(n) on the left, its satisfaction set S(n) on the centre and 
its permission set P(n) on the right. These sets are initially empty, and they do not change except in 
two cases, a) when either a obligation or a prohibition is violated or satisfied, b) when a permission is 
performed. 

Let us recall that the intuitive meaning of an NTA is the parallel composition of several timed au- 
tomata. We consider a set of actions ACT , in which we have the following actions: 

• An internal action X G ACT . • A synchronization action m G ACT that 

• An input action ml G ACT comes from a synchronization of an input ac- 

. __ tion ml and an output action ml. 

• An output action ml G ACT. 

The semantics of timed automata is well known [1J. It is based on a timed labelled system, where 
states are pairs s = («, v) where n is a node of the automaton and v is a valuation of the clocks. There are 
two types of transition: 

• timed transition^ s s'(d G IR + ) • and action transitions s s'(a G ACT). 

A Network of Timed Automata (NTA) is then defined as a set of timed automata that run simultane- 
ously, using the same set of clocks, and synchronizing on the common actions. Internal actions can be 
executed by the corresponding automata independently, and they will be ranged over the letters a,b,... 
whereas synchronization actions must be executed simultaneously by two automata. Synchronization 
actions are ranged over letters m,m',... and they come from the synchronization of two actions ml and 
ml, executed from two different automata^- 

The operational semantics of a network of timed automata has the following transitions: 

• A delay transition of d time units requires that all the involved automata are able to perform this 
delay individually. 

• Autonomous action transitions that correspond to the evolution of a single timed automaton. 

• Synchronization transitions that require two automata to perform two complementary actions, ml 
and ml, respectively. 



'Timed transitions only change the valuation of clocks. 

2 In the original definition the only internal action is T, and synchronizations always yield internal actions. 
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Figure 2: Automata for the Payment_Shipment example, Ao and Ai 
Definition 3 (Semantics of an NTA) 

LetN = (Ai,,...,Ak)be an NTA. A state of N is a tuples = (ji , . . . , Sk), where si is a state of the automaton 
Ai (for i=l,...,k). We have the following transitions: 

• Timed transitions. If VI < j < k : sj — s'j, then: (s\ , . . . ,Sk) > (s\ ,s' k ) with d € IR + . 

• Autonomous transitions. If 31 < j < k : sj — s'j for a € ACT, a^m\ and a 7^ ml, then: 

(s U ...,Sj,...S k ) Oi , . . . ,s'j, . . . s k ). 

• Synchronization transitions. 31 <i,j<k: sj s'j, Sj s\ for ml, ml E ACT, then: 
(. . . ,Sj, . . . ,S[, . . . , ) > (...,/•,... ,s' t , .. .), assuming that j < i, the other case is similar. 

The complete semantics for C-0 Diagrams in terms of NTAs translation can be found in ifTTl . Figure 
12 shows the resulting NTA once these transformations are applied over the Payment ^Shipment example. 
This NTA consists of two automata running in parallel, that is, NTAp&s = {Ao,Ai}. Automaton Ao is 
where the main part is translated and the starting point of this example. The main translated structures 
we can observe here are the three kind of refinements and the reparation of a violated clause. Besides 
these main structures, we can see how guards and time restrictions are translated. 

In Ao, this contract starts with a SEQ-refinement of two clauses 2 and 5, which assemble in sequence 
via the transition between nodes n-j and rag, that is, the end of clause 2 and the beginning of clause 5, 
respectively. From node rao, where clause 2 starts, we may reach either «2 or 714, which correspond 
to an OR-refinement representing the payment made either by credit card or paypal. Node n^ only 
captures termination in the event that that the time for the payment expires without performing any of 
these actions. Notice that once the payment has been done (nodes 723 or n$) we move into node 717, 
from which the "sending item action" clause 5 starts, which corresponds to action 03. In this case we 
have 14 time units. If this time expires and the client has not received the item the reparation clause 
is activated (node «io). In this case we have an AND-refinement, so a second timed automaton (A\) 
is created, which corresponds to the right-hand side part of the AND-refinement (the left-hand side is 
performed by Ao). Both automata synchronize at their beginning and at their termination in order to be 
executed simultaneously. The obligation to refund the money is captured by action c?4 in Aq, whereas the 
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permission to penalize the seller is captured by action a 5 in A\. Over-line actions label those transitions 
enabled when the main action is not performed. 

Guards are here translated as guards in the transitions and time restrictions are used to denote the 
invariants of certain states and some guards in transitions, which determine whether a clause is satisfied 
in time. In reference to the different violation, satisfaction and permission sets, we will comment the 
most significant ones, which correspond with the maximal paths except when a reparation is defined. 
Violation sets V6, VIO and V13 consist of the violated clauses: either clause 3 or 4, clause 5 and clause 
7, respectively. The satisfaction set 515 will consist of clauses 3 or 4 (depending on the payment is made 
either by credit card or paypal), and either clause 5 (if the item has been sent on time) or clause 7 (if the 
clause 5 has been repaired). Finally, permission set P15 is either empty or clause 8 (if we have followed 
the reparation and the permission to penalize the seller has been performed). 

4 Conformance relations 

In this section we define a set of conformance relations to establish whether an implementation of a 
contract conforms to the contract we want to satisfy. We will consider a semantic relation inspired in the 
conformance testing relation given in lfl4l . We take as starting point a normative document written in 
terms of a C-0 Diagram, which is then translated into a network of timed automata. We also consider 
an implementation I of this contract which is also provided as an NTA, with at least the same actions we 
had in the contract. We intend to define a black box conformance relation, which means that we do not 
know how the implementation has been done, so we can only use the information about the actions it 
performs. 

Definition 4 A timed trace is a sequence \a\d\a2d2 • ■ -CL n d^\ G (ACT x IR + )*. We will use the symbols 
t, h, ?2. t n> ... to denote traces. The empty trace is denoted by []. The concatenation of t\ and ti will be 
denoted by t\ ■ ?2- We will say that t\ is a subtrace of t 2 , written t\ < t<i, if there is a trace t such that 
t 2 =h- 1. 

Let N be an NTA, where we define the timed computations of N as follows: 

_ _ 

• s^=^ s. 

t\ad] — _ _ _ 

• s > s' for a € ACT and d € IR if there exist states s\ ,s\, . . . , ,si,Sj ofN with I > 1 such that 

- t d\ —r % dl —f —, X di —t a —7 , , 7 

s=> si — > s l — > S2 — > $2'" ^ s i-\ — ^ s i — s i — ^ s an d d = Li<i<idi 

We define the set of timed traces ofN as tr(N) = {t \ 3s : sq =4> s}, being so the initial state ofN. 

The following definition extends the sets V, S and P to traces, by accumulating the contents of the 
respective sets V, S, P over the traversed nodes until reaching the final node of the trace. 

Definition5 Let N = (Ai,...Aj) be an NTA and t E tr(N), we define the sets of violation (denoted 
\/(N,t)), satisfaction (denoted S(N,t)), and permission (denoted P(N,t)) as follows: 

• V(N,t) = {\J l < i < k V(n i )\so^(s' 1 ,..., S ' k ), iJ = (ni,Vi)} 

• S(N,t) = {Ui<k*;%<) I ^o=> K>---)4)> 4 = (m,vi)} 

• P(N,t) = {\J 1 < i < k P(n i )\^A( S ' 1 ,..., S ' k ), s\ = (n h v/)} 

Where sq is the initial state ofN. We say that t is a good trace, denoted by t € good (,/V) if it is maxima^ 
VSeS(N,t): S^0, andW EV(N,t): V = 0. 

We say that t is a clean trace, denoted by t G clean (N), if V/' <t : V(N,t') = {0}. 
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Table 1: Trace examples for NTAp&s- 



Comming back to our running example NTAp&s, let us analyse the following maximal traces of Table 
CD The good traces will be t\, ?4 and t$ since their violation sets are empty but not their satisfaction sets. 
From these traces only t\ corresponds to a clean trace since ?4 and t$ have violated the shipment clause 
5, however they have been recovered via/?i. 

Definition 6 Let C be an NTA corresponding to a C-0 diagram. We say that C is consistent if the 
following conditions hold: 

• clean (C) ngood(C) 7^ 0. This means that there is a way to meet contracts without making any 
violations. 

• Vera £ CN 3t £ clean(C) Pi good(C) : 3S £ S(C,t) : cn £ S. That is there is a way to meet all 
obligations and prohibitions without making any violation. 

Our NTAp&s example satisfies both conditions since trace t\ is a good and clean trace that meets 
both obligations, the payment and the shipment. 

As we have indicated previously, we assume that implementations are given as networks of timed 
automata. Implementations usually need to implement a single action by making several simple actions. 
For instance let us suppose that a contract specifies that a payment can be done by credit card. When 
implementing the payment procedure, several invisible steps like connecting with the bank or checking 
the credit card should be performed. All these actions are not considered in the specification of the 
contract and they should not be taken into account. All we need in this case is the amount of time 
required to perform these actions. Thus, these implementation traces may contain actions that are not 
considered in the contract, so we need to hide these actions. 

Definition 7 Let us consider ACT C ACT' and t £ {ACT' x IR+)*. We consider the operator hide^cr 
defined as follows: 

. hide Acr ([]) = [] 

• hideAcr([«<i] = [ad\ • hideAcr(0/ or fl €ACT, a/t 

• hide^crQfl^] -t) = d + hideAcr(0/ or a ^ACT or a = X, where the operator + adds d units of time 
to the last action oft. Formally it is defined as follows: 

-d+[} = [] 

- d+{[ad\] -t) = [a{d\ +d)]-t 



3 A maximal trace is a trace that cannot be extended anymore: if t £ tr(2V) but t ■ [ad] fL tr(iV) for all a e ACT and d 6 IR + . 
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Let us consider the following trace t(, = [a\3a' 3 2a 3 2a^4] belonging to a possible implementation of 
our contract. The actions a' 3 and a" are internal actions of the implementation (for instance the seller 
obtains the deliver company list related to the shipment address a 3 and sends the shipment info to the 
deliverer a"). Therefore, the result of hide^cr^) = [«i3a38], where the internal actions have been 
omitted and the intermediate time delays are 2 + 2 + 4 = 8. 

Now, we have all the machinery needed to define our conformance relation. We will consider that an 
implementation satisfies a contract if a) there is at least one trace that execute all the actions expressed in 
the obligations in due time, and not any actions from the prohibitions; that is, satisfying all the obligations 
and prohibitions expressed in the contract, and b) if at any time a violation occurs, then it will be repaired 
in the future. In our example, the ideal implementation should be able to "allow the user to at least pay 
with either credit card or paypal in 3 days, and then, the seller send the item in time". This ideal behavior 
is represented by condition a), since it gathers all contract obligations and prohibitions. However we 
should be most realistic and think that all systems are prone to errors, then implementations can as well 
fail in some occasions. But if they do, then they should been able to recover somehow. That is the idea 
behind the second condition, that is, if a seller does not send the item, he should at least refund the buyer. 

Definition 8 Let us consider a consistent contract specification C and an implementation I, we say that 
I conforms C, written 7 conf C, iff 

• For any cn G CN there exists t G tr(7) such that hideAcr(0 £ clean(C) Ugood(C) and 3S € 
S(I,h\de A cr(t)) : cn G S. 

• If there exists t G tr(7) and cn G CN with 3V G V(C, hide^cr(O) • cn G ^> there exists t' such that 
t-t' G tr(7) such that W\de A cr(t ■ G tr(C) and W G V(C, hide Acr (7 • t')) : cn G" V'. 

Let us consider the following implementations I\, I2 and 73 where tr(7i) = {h,t2}, tr(h) = {£4} 
and tr(73) = {/i,^} of our running example NTAp&s- The implementation 7} satisfies the first condition 
since t\ is good and clean and satisfies all the cn G CN, although it does not satisfies the second because ti 
violates clause 5, which is never repaired. Thus implementation l\ does not conform the given contract. 
Regarding to I2, we have the opposite situation, here trace t^ violates the clause 5, but reparation 7?i is 
now applied to refund the buyer. Therefore this trace satisfies the second condition but not the first one 
because it does not includes all the cn G CN. Finally, implementation 73 is the only one that conforms 
the contract written as 73 conf NTAp&s, since it includes t\ and t2, which fulfil both conditions. 

We are now interested in a comparison of different implementations of a consistent contract, taking 
into account the permissions allowed for each implementation. This comparison will be based on the 
permissions performed by an implementation in such a way that an implementation will be considered 
better than other if it is able to perform more permissions. In our example we can consider two imple- 
mentations, one that after the seller refunds the buyer (because the item has not been sent), allows him to 
penalize the seller; and other implementation, which does not allow penalizations. In this case, we will 
say that the first one is better than the former one. 

Definition 9 Let us consider a consistent contract specification C and two implementations I\ and I2 
such that I[ conf C and I2 conf C. We say that I[ is better with respect to the permissions than I2, written 
h <p7i iff for any t2 G tr(72) such that W G V(C, hide^crfe)) -V = there is a trace t\ G tr(7j ) such that 
W G V(C,hide A cr(^i)) :V = and for any Pi G P(C, hide A cr(/i)) there exists p 2 G P(C,W\de A cT(t 2 )) 
such that P2 C?!. 

Let us consider two new implementations I4, I5, where tr(7t) = [^1,^4] and tr(7s) = [h,ts]. Both I4 
and 75 conform to C, as they have at least one trace {t\) fulfilling all the obligations and prohibitions, and 
traces t\ for 74 and ts for 7s violate a clause, but the corresponding reparation is performed on time. That 
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Figure 3: Payment_Shipment implementation example. 



implies that both I4 and 1$ conf NTAp&s. However, the permission set for I4 is empty, whereas for 75 
clause 8 is the permission set. Thus, P 4 C P 5 , implying that h<pl$. 

In Figure an implementation of the Pctymen Shipment example Ip&s is presented where Ip&$ = 
{Ap>,ApG,AsYs}- A$ys is the main automata where the main actions concerning to the contract are im- 
plemented. Ap and Apq implement the behaviors of a deliverer and a payment gateway, both automata 
present some doted lines to describe a set of internal actions that we abstract to simplify the example. All 
the actions described in these two automata are synchronization actions whose counterparts are defined 
in the main automata. The deliverer automaton consists of three actions: the first one is used to start 
the deliverer process by receiving the item data and delivery address, then, the second one and the third 
are used to inform the seller whether the delivery has succeed within a time window of 10 days. The 
payment gateway is in charge of performing two processes: charging the buyers credit card and perform 
the refund if needed. They are performed via actions a[_ and actions a' A _ where fail and ack actions 
are used to communicate whether the operation has succeed or not, respectively. 

Let us now analyze this implementation. The main answer to decipher is if /p&^conf NTAp&s- We 
can observe that the above defined trace t\ is obtained hiding the following trace t[ = W l _ jn f o 0a[_ ack 3 

a i® a 3-data® a 3-ack& a s®]' that i s > h = hide^cr^! ), and t[ G tr (//>&$). As we have shown before, t\ 
satisfies the first condition. Regarding to the second condition, note that when a contract is broken it is 
not necessary that the contract is always repaired, but it should exist at least one trace allowing i S This 
occurs in trace t$, which can be obtained hiding the Ip&s trace t' 4 = [a[_ jn ^ o a[_ ack 2 a\0 a^\5 a\_ begin 
a '\-ack^ an d substituting ai by a\, that is, substituting the equivalent actions "paypal" payment for 
a "credit card" payment. Thus, we show that the conformance relation is held by our example, since it 
fulfils both criteria. 

5 Conclusions 

In this paper we have used the formal semantics based on NTAs (Network of Timed Automata) for nor- 
mative contracts written in terms of C-0 diagrams introduced in iflOl in order to define a conformance 
relation between a contract and an implementation. We have introduced the notion of consistent contracts 



4 Cont variable is used to force the refund for three times. If the refund is not feasible then a fail action is executed. 
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on the basis on their corresponding NTA, as those NTAs that allow to find final traces without violating 
any clauses. Then, implementations of contracts are also NTAs, which must satisfy all the obligations 
and prohibitions, or in the event of a violation, implement the corresponding reparation. These imple- 
mentations are said to be conforming to the contract. We have also presented a first comparison relation 
between implementations, on the basis of the permissions allowed for each one. We intend to define a 
set of implementation comparisons, taking into account the number of clauses that have been violated, 
or assigning a weight to some clauses, thus considering some clauses as more important. 

References 

[1] R. Alur & D.L. Dill (1994): A Theory of Timed Automata. Theoretical Computer Science 126(2), pp. 183— 
235, doi jlO . 1016/0304-3975 (94) 90010-"8) 

[2] D. Chiu, S. Cheung & S. Till (2003): A Three-Layer Architecture for E-Contract Enforcement in an E-Service 
Environment. Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS-36), pp. 
74-83, doi jlO .110 9/HICSS . 2003.11741881 

[3] F. Dignum & H. Weigand (1995): Modelling Communication between Cooperative Systems. Pro- 
ceedings of Advanced Information Systems Engineering (CAISE'95), pp. 140-153, doi:10.1007/ 
13-540-59498- 1_243] 

[4] G. Governatori, Z. Milosevic & S. Sadiq (2006): Compliance checking between business processes and 
business contracts. Proceedings of the 10th IEEE Conference on Enterprise Distributed Object Computing, 
pp. 221-232, doi jlO . 1109/EDOC . 2006722] 

[5] J. Hatcliff, GT. Leavens, k.R.M. Leino, P. Muller & M. Parkinson (2009): Behavioral Interface Specification 
Languages. Technical Report CS-TR-09-01, School of EECS, University of Central Florida, doi: 10 . 1145/ 
2187671.21876781 

[6] PR. Krishna, K. Karlapalem & A.R. Dani (2005): From Contract to E-Contracts: Modeling and Enactment. 
Information Technology and Management 6(4), pp. 363-387, doi jlO . 1007/sl0799-005-3901-z[ 

[7] A. Lomuscio, H. Qu & M. Solanki (2008): Towards verifying contract regulated service composition. Pro- 
ceedings of IEEE International Conference on Web Services (ICWS 2008), pp. 254-261, doij lO . 110971 
ICWS .200 871151 

[8] O. Marjanovic & Z. Milosevic (2001): Towards formal modeling of e-Contracts. Proceedings of 5th IEEE 
International Enterprise Distributed Object Computing Conference, pp. 59-68, doi: 10 . 1109/EDOC . 2 001 . 

19504231 

[9] E. Martinez, G. Diaz & M. E. Cambronero (2011): Contractually Compliant Service Compositions. ICSOC 
2011 - The Ninth International Conference on Service Oriented Computing, pp. 636-644, doij lO . 1007/1 
|978-3-642-25535-9_50| 

[10] E. Martinez, G. Diaz, M. E. Cambronero & G. Schneider (2010): A Model for Visual Specification of e- 
Contracts. In: The 7th IEEE International Conference on Services Computing (IEEE SCC'10), pp. 1-8, 
doi jlO. 1109/SCC . 2010 . 32[ 

[11] E. Martinez, G. Diaz, M. E. Cambronero & G. Schneider (2012): Specification and Verification of Norma- 
tive Specifications using C-0 Diagrams, [https : //www . dsi . uclm . es/descargas/thecnicalreports/| 
|DIAB-12-05-l/TSEll.pdf[ 

[12] P. McNamara (2006): Deontic Logic. In: Gabbay, D.M., Woods, J., eds.: Handbook of the History of Logic, 
7, North-Holland Publishing, pp. 197-289, doi jlO. 1016/S1874-5857 (06) 8002^4] 

[13] J. C. Okika & A. P. Ravn (2008): Classification ofSOA Contract Specification Languages. In: 2008 IEEE 
International Conference on Web Services (ICWS'08), IEEE Computer Society, pp. 433-440, doi jlO . 110971 
ICWS. 2008. 36. 

[14] J. Tretmans (1999): Testing Concurrent Systems: A Formal Approach. In: CONCUR'99, LNCS 1664, 
Springer, pp. 46-65, doi jlO . 1007/3-540-48320-9_6| 



